1. Field of the Invention
This invention relates to technologies to allow program objects being executed by processes outside a virtual machine process to be accessed via standard or “normal” class loading operations by program objects being executed inside the virtual machine process.
2. Background of the Invention
Object-oriented programming (“OOP”) methodologies are well known and widely adopted, as they promote efficient team development of software products, allow minimized maintenance activities, and provide abilities to easily and dependably integrate modules and objects from older designs, other designers, and new designs together.
In contrast to procedural programming methodologies, OOP allows programmers to define data types of data structures and types of operations or functions which can be performed on those data structures, which defines the data structure as an “object”. Relationships between objects may be defined, as well, such that some objects may share or “inherit” characteristics from other objects, allowing variations of existing objects to be quickly and efficiently developed. Categories of objects are referred to as a “class” of objects. Objects of a given class share common properties as defined by the class.
A number of companies have developed and marketed software development tools which support OOP programming languages (“OOPL”), including but not limited to Xerox Corporation's Smalltalk, Bell Laboratory's C++, Microsoft Corporation's Visual C++, Sun Microsystems' Java, and Open Management Group's (“OMG”) Unified Modeling Language (“UML”) are programming languages which, among others, implement OOP concepts and methodologies.
In particular, Sun Microsystem's Java language has gained widespread use for its support of Internet technologies, such as “applets” and embedded Java scripts in web pages, “servlets” which can be run by a web server or application program server, etc. Java is especially useful for its portability or non-machine-specific design, which enables Java code to be run or executed by any computing platform which is equipped with a Java interpreter. The “open” nature of Sun's Java specifications has also allowed many vendors to participate in the marketplace, whether by developing and providing application programs, administrative tools, or programming tools.
Java code is pseudo-compiled into “bytecode”, which is later executed by a machine-specific Java interpreter. The interpreter converts the bytecodes to machine-specific instructions which are executed by the particular computer on which the Java program is being executed. Java defines the virtual computer for which the bytecode is designed as a “virtual machine”, and thus, programming is done as if it is to be executed by the theoretical virtual machine. During actual execution on a computer, one or more Java Virtual Machines (“JVM”) may be created by the computer's operating system, each JVM executing Java programs as if it were a real, independent computer. Java code can also be converted directly into machine-specific executable language using a special compiler, the results of which may also be executed within a JVM.
An enterprise server generally refers to a mainframe class computer which is suitable for running programs of a magnitude commensurate with an “enterprise”, such as making bulk airline reservations online, tracking large real time trading and commodities, etc. Java 2 Platform Enterprise Edition (“J2EE”), which was developed by Sun Microsystems with other notable partners such as International Business Machines (“IBM”), provides a Java-compliant platform for enterprise class computers, and is in many ways a subset of functionality of the Java 2 Platform Standard Edition (“J2SE”).
J2EE provides several key features which make it useful in enterprise computing environments, including support for a “thin client” tiered arrangement between client computers and servers, as well as supporting platform-independence of modules and code (e.g. portability) so that vendors may easily target a wide array of enterprise computers with a single design of software.
Additionally, J2EE supports Common Object Request Broker Architecture (“CORBA”), and a more Java-specific and further evolved Enterprise Java Beans (“EJB”) concept. CORBA and EJB concepts allow objects to “discover” the existence and availability of other classes and objects which they may need for data or processing functions, and to utilize instances of those objects on an as-needed basis, whether running on the same computing platform or working together over a computer network. In particular, EJB is a server-based technology for the delivery of program components in an enterprise environment. EJB supports the Extensible Markup Language (XML) to define Java Beans (e.g. program modules which are designed conformant to the Java Component Architecture), and provides enhanced deployment and security features which have gained it rapid adoption by many enterprise server owners and operators.
Java Message eXtensions (“JMX”) is the Java specification which, if implemented by an vendor of a software product, allows software developers to easily integrate their new designs with existing network management solutions. To take advantage of JMX, objects are written compliant to the standard as “MBeans” (e.g. “manageable Java Beans”). A JMX client can invoke methods and access attributes of MBeans via a JMX container in which they reside. Additionally, clients can “register” with an MBean to receive notifications as needed.
The term “application server” is used widely to refer to a program running on a computer which provides a function needed by a client computer, such as a web server as related to a web browser, or a banking database server as related to a Automated Teller Machine (“ATM”). Application servers can be small, insubstantial programs executed by computing platforms with minimal resources, they may be substantial programs (e.g. groups of many objects) running on enterprise class computers, or any combination there between.
Application servers, clients, computer networks, OOP, OOP languages, Java, J2EE, JMX and MBeans are all well known in the art, and information regarding these concepts and specifications is openly available from the vendors mentioned.
Turning to FIG. 1, one possible arrangement (10) in an application server (“AppServer”) is shown in which multiple client or customer application modules (22a, 22b, . . . 22n) are executed within the same AppServer process such as J2EE-compliant AppServer JVM process as a tool user interface (“UI”) module (24). The application modules (22a, 22b, . . . 22n) are represented in this example by Enterprise Archives (“EAR”), which are containers of multiple Java objects. The Tool UI (24) may directly access administrative information about the other modules within the same AppServer JVM process (21) using standard JMX application programming interface (“API”) calls, and thus the tool module may provide administrative functions such as console operations, statistical reports, etc. Because Java allows for easy integration and cooperation of modules by different vendors, the vendors of the tool module(s) and application modules may be many.
However, by running the Tool UI (24) module(s) in the same JVM (21) as the customer's application modules (22a, 22b, . . . 22n), several undesirable issues arise. First, the JVM processing bandwidth is divided between all the modules running in it, so a tool module or process may negatively impact the performance of an application process. Additionally, the running of tool modules in the same AppServer as application processes may represent a security issue. As such, many owners of enterprise servers have adopted policies that only application modules may be run in their AppServer JVM's, and all other administrative and support modules must be run in other JVM's.
In addition, many enterprise server owners have experienced difficulties getting effective diagnosis and support of problems which arise when application modules from a wide variety of vendors are run inside the same JVM. So, many of them have adopted even stricter policies that only application modules from the same vendor or supplier may be run in an AppServer JVM.
So, tool vendors for such application servers are forced to design their modules for execution outside the AppServer JVM where application modules are running. However, J2EE AppServers do not allow modules which are running outside of an AppServer JVM to introspect into modules running inside the AppServer JVM, which prevents tool modules running outside the AppServer JVM from obtaining administrative information regarding modules running within the AppServer JVM.
One attempt to solve this problem is shown in FIG. 2. In this approach, the tool vendor may place a minimized module or servlet (23) into the AppServer JVM (23). The Classloader Tooling EAR (23) exports information to a set of tools (24) running outside the AppServer JVM (21). This approach, though, means that application modules must perform proprietary or non-J2EE-standard operations to load interface or class information about the tools from the tool module. This means that in order for the tools to be effective, the application modules must be designed to take advantage of non-standard interfaces, which makes the application modules less portable and less reusable in environments that have other configurations. Also, while minimizing the performance impact of placing an non-application module in the AppServer process, it still may produce a security problem and technically still violates the policies of many enterprise server owners and operators.
Therefore, there is a need in the art for a system and method which provides external access by tools for information regarding the performance and administration of application modules running within an application server process such as a J2EE AppServer JVM, without the need for the tools to run within the same JVM as the application modules, and without the need for the application modules to implement custom or proprietary application programming interfaces.